161 research outputs found
A multi-paradigm language for reactive synthesis
This paper proposes a language for describing reactive synthesis problems
that integrates imperative and declarative elements. The semantics is defined
in terms of two-player turn-based infinite games with full information.
Currently, synthesis tools accept linear temporal logic (LTL) as input, but
this description is less structured and does not facilitate the expression of
sequential constraints. This motivates the use of a structured programming
language to specify synthesis problems. Transition systems and guarded commands
serve as imperative constructs, expressed in a syntax based on that of the
modeling language Promela. The syntax allows defining which player controls
data and control flow, and separating a program into assumptions and
guarantees. These notions are necessary for input to game solvers. The
integration of imperative and declarative paradigms allows using the paradigm
that is most appropriate for expressing each requirement. The declarative part
is expressed in the LTL fragment of generalized reactivity(1), which admits
efficient synthesis algorithms, extended with past LTL. The implementation
translates Promela to input for the Slugs synthesizer and is written in Python.
The AMBA AHB bus case study is revisited and synthesized efficiently,
identifying the need to reorder binary decision diagrams during strategy
construction, in order to prevent the exponential blowup observed in previous
work.Comment: In Proceedings SYNT 2015, arXiv:1602.0078
Synthesis from multi-paradigm specifications
This work proposes a language for describing reactive synthesis problems that integrates imperative and declarative elements. The semantics is defined in terms of two-player turn-based infinite games with full information. Currently, synthesis tools accept linear temporal logic (LTL) as input, but this description is less structured and does not facilitate the expression of sequential constraints. This motivates the use of a structured programming language to specify synthesis problems. Transition systems and guarded commands serve as imperative constructs, expressed in a syntax based on that of the modeling language Promela. The syntax allows defining which player controls data and control flow, and separating a program into assumptions and guarantees. These notions are necessary for input to game solvers. The integration of imperative and declarative paradigms allows using the paradigm that is most appropriate for expressing each requirement. The declarative part is expressed in the LTL fragment of generalized reactivity(1), which admits efficient synthesis algorithms. The implementation translates Promela to input for the Slugs synthesizer and is written in Python
Validating Requirements for Fault Tolerant Systems Using Model Checking
Model checking is shown to be an effective tool in validating the behavior of a fault tolerant embedded spacecraft controller. The case study presented here shows that by judiciously abstracting away extraneous complexity, the state space of the model could be exhaustively searched allowing critical functional requirements to be validated down to the design level. Abstracting away detail not germane to the problem of interest leaves by definition a partial specification behind. The success of this procedure shows that it is feasible to effectively validate a partial specification with this technique. Three anomalies were found in the system one of which is an error in the detailed requirements, and the other two are missing/ambiguous requirements. Because the method allows validation of partial specifications, it also is an effective methodology towards maintaining fidelity between a co-evolving specification and an implementation
A multi-paradigm language for reactive synthesis
This paper proposes a language for describing reactive synthesis problems that integrates imperative and declarative elements. The semantics is defined in terms of two-player turn-based infinite games with full information. Currently, synthesis tools accept linear temporal logic (LTL) as input, but this description is less structured and does not facilitate the expression of sequential constraints. This motivates the use of a structured programming language to specify synthesis problems. Transition systems and guarded commands serve as imperative constructs, expressed in a syntax based on that of the modeling language Promela. The syntax allows defining which player controls data and control flow, and separating a program into assumptions and guarantees. These notions are necessary for input to game solvers. The integration of imperative and declarative paradigms allows using the paradigm that is most appropriate for expressing each requirement. The declarative part is expressed in the LTL fragment of generalized reactivity(1), which admits efficient synthesis algorithms, extended with past LTL. The implementation translates Promela to input for the Slugs synthesizer and is written in Python. The AMBA AHB bus case study is revisited and synthesized efficiently, identifying the need to reorder binary decision diagrams during strategy construction, in order to prevent the exponential blowup observed in previous work
Understanding GCC Builtins to Develop Better Tools
C programs can use compiler builtins to provide functionality that the C language lacks. On Linux, GCC provides several thousands of builtins that are also supported by other mature compilers, such as Clang and ICC. Maintainers of other tools lack guidance on whether and which builtins should be implemented to support popular projects. To assist tool developers who want to support GCC builtins, we analyzed builtin use in 4,913 C projects from GitHub. We found that 37% of these projects relied on at least one builtin. Supporting an increasing proportion of projects requires support of an exponentially increasing number of builtins; however, implementing only 10 builtins already covers over 30% of the projects. Since we found that many builtins in our corpus remained unused, the effort needed to support 90% of the projects is moderate, requiring about 110 builtins to be implemented. For each project, we analyzed the evolution of builtin use over time and found that the majority of projects mostly added builtins. This suggests that builtins are not a legacy feature and must be supported in future tools. Systematic testing of builtin support in existing tools revealed that many lacked support for builtins either partially or completely; we also discovered incorrect implementations in various tools, including the formally verified CompCert compiler
Recommended from our members
Establishing Flight Software Reliability: Testing, Model Checking, Constraint-Solving, Monitoring and Learning
In this paper we discuss the application of a range of techniques to the
verification of mission-critical flight software at NASAâs Jet Propulsion Laboratory.
For this type of application we want to achieve a higher level of confidence than can
be achieved through standard software testing. Unfortunately, given the current state
of the art, especially when efforts are constrained by the tight deadlines and resource
limitations of a flight project, it is not feasible to produce a rigorous formal proof of
correctness of even a well-specified stand-alone module such as a file system (much less
more tightly coupled or difficult-to-specify modules). This means that we must look for
a practical alternative in the area between traditional testing and proof, as we attempt
to optimize rigor and coverage. The approaches we describe here are based on testing,
model checking, constraint-solving, monitoring, and finite-state machine learning, in
addition to static code analysis. The results we have obtained in the domain of file systems
are encouraging, and suggest that for more complex properties of programs with
complex data structures, it is possibly more beneficial to use constraint solvers to guide
and analyze execution (i.e., as in testing, even if performed by a model checking tool)
than to translate the program and property into a set of constraints, as in abstraction-based
and bounded model checkers. Our experience with non-file-system flight software
modules shows that methods even further removed from traditional static formal methods
can be assisted by formal approaches, yet readily adopted by test engineers and
software developers, even as the key problem shifts from test generation and selection
to test evaluation.Keywords: Verification, Formal proof, Flight software, File systems, Model checking, Testin
- âŠ